[GTK3] Fix ToolBar.computeSize 60 Hz repaint loop with SWT.WRAP#3240
Conversation
05ec74d to
29468e1
Compare
|
Very good catch. The snippet is good for testing but it is not smth that any SWT user can use as an example so it shouldn't end up in snippets whenever the PR is merged. |
|
With the requested changes in Toolbar GTK3.gtk_toolbar_set_show_arrow will no longer be needed so it can be removed too. |
|
971ec6c to
8428c35
Compare
|
Changes in GTK3.java should have caused changes in gtk3.c and gtk3_stats.h |
8428c35 to
b2fce68
Compare
I do not see how. The gtk-dev-guide.md mentions that "SWT Tools also generates JNI bindings (i.e. os.c, os_stat.c, etc.) for you automatically." but my SDK build does not have the SWT Tools installled. And mvn clean install '-Dnative=gtk.linux.x86_64' -DskipTests does also not do this. Manually updated gtk3.c. The stats files (gtk3_stats.c/gtk3_stats.h) didn't seemt to have an entry for this function. |
|
SWT tools work only as eclipse plugin and do their work on save of java file as regular builder. The entry in gtk3_stats is gtk_1toolbar_1set_1show_1arrow_FUNC but I would prefer to see the changes done by the builder manually to reduce extra changes in other PRs where swt tools do the work. |
As discussed via chat the tools usage is not document nor part of the SDK build. I will suggest to @HannesWell to document the usage in his pending #3212 for documention improvements
|
Remove all gtk_toolbar_set_show_arrow usage from ToolBar: both the toggle in computeSizeInPixels (added in 2012 for Bug 46025) and the toggle in setBounds. WRAP is not supported on GTK and the show_arrow flag was being misused to work around a GTK3 sizing bug from the GTK 3.4 era that no longer applies on modern GTK 3.24. The workaround in computeSizeInPixels caused two GTK state transitions per measurement, each triggering gtk_widget_queue_resize -> gtk_widget_queue_draw -> gdk_window_invalidate_region. When a SWT.WRAP ToolBar sits inside a frequently-measured parent (e.g. CTabFolder.setTopRight), this created a self-sustaining ~60 Hz repaint loop that burns 10-25% CPU while idle. With no remaining callers, the gtk_toolbar_set_show_arrow native binding is removed from GTK3.java as well. Fixes eclipse-platform#3236 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
b2fce68 to
07a989d
Compare
|
Coooool. After installing the swt.tools the c files get updated. Very nice feature. Would be nice if that would also be baked into the command line build. @akurtakov PR updated as requested. |
|
I'm updating jnigen in eclipse-platform/www.eclipse.org-eclipse#535 - outdated version available at https://eclipse.dev/eclipse/swt/jnigen.html |
|
Any further concerns about this PR @akurtakov ? |

Summary
gtk_toolbar_set_show_arrowtoggle workaround inToolBar.computeSizeInPixelsthat caused two GTK invalidation cycles per measurement callSWT.WRAPToolBar sits inside a frequently-measured parent (e.g.CTabFolder.setTopRight), the toggle created a self-sustaining ~60 Hz repaint loop burning 10-25% CPU while idleTest plan
SWT.WRAPand confirm CPU stays at 0% on idleSWT.WRAPtoolbar overflow behavior still works correctly (items hidden behind chevron when toolbar is too narrow)Fixes #3236
🤖 Generated with Claude Code